Scenario #9035: A Global Admin Can Deactivate a Removed Subject

UseCase Deactivate Subject Via Synchronization => SubjectSync: sync-alice - deactivated

When a user or group is disabled or removed in Keycloak, the sync program synchronizes the desired state with deactivated: true through the same UUID-keyed create-or-update PUT /api/rbac/subjects/{subjectUuid} it uses for creating and renaming subjects. The subject is then soft-deleted: its row and its grants are retained, but it is excluded from all read paths; re-synchronizing with deactivated: false (or without that property) reactivates the subject.

Properties

Required

• SubjectSync: sync-alice - renamed to sync-alicia from 9033: Re Synchronizing an Existing Subject Updates Its Name Idempotently

Given

name	value
subjectUuid	238a0001-0000-0000-0000-000000000001
subjectName	sync-alicia
subjectType	USER

Synchronize the subject as deactivated via PUT

HTTP PUT "/api/rbac/subjects/238a0001-0000-0000-0000-000000000001" // SubjectSync: sync-alice \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }` \
  <<EOF
{
  "name" : "sync-alicia",
  "type" : "USER",
  "deactivated" : true
}
EOF
=> status: 200 OK 

The deactivated subject is no longer visible

HTTP GET "/api/rbac/subjects/238a0001-0000-0000-0000-000000000001" // SubjectSync: sync-alice \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }`
=> status: 404 NOT_FOUND 

---

generated on 2026-08-10 01:38:10 for branch